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Abstract. Numerous systems for dissemination, retrieval, and archiving 
of documents have been developed in the past. Those systems often focus 
on one of these aspects and are hard to extend and combine. Typically, 
the transmission protocols, query and filtering languages are fixed as well 
as the interfaces to other systems. We rather envisage the seamless estab- 
lishment of networks among the providers, repositories and consumers 
of information, supporting information retrieval and dissemination while 
being highly interoperable and extensible. 

We propose a framework with a single event-based mechanism that uni- 
fies document storage, retrieval, and dissemination. This framework of- 
fers complete openness with respect to document and metadata formats, 
transmission protocols, and filtering mechanisms. It specifies a high-level 
building kit, by which arbitrary processors for document streams can be 
incorporated to support the retrieval, transformation, aggregation and 
disaggregation of documents. Using the same kit, interfaces for different 
transmission protocols can be added easily to enable the communication 
with various information sources and information consumers. 



1 Introduction 

The purpose of digital libraries is the archiving of electronic documents and the 
support of their retrieval and dissemination. We observe digital libraries as "in- 
formation dissemination networks" (IDNs), the nodes of which are information 
providers, such as authors and publishers, repositories (e.g. libraries, techni- 
cal report servers), and information consumers. The links among them may be 
short-term, as in the case of a literature recherche, or long-term, as for the sub- 
scriptions to alerting services and the mirroring of repositories. Such networks 
must support various document and metadata formats, transmission protocols, 
and heterogeneous query languages and filters. 

In this work, we present a unifying framework for the construction of IDNs. 
It consists of a simple conceptual model and an event-based mechanism for 
dissemination and retrieval of information. An implementation of our "NPC" 
framework provides a building kit consisting of Nodes, Ports and Channels. 

Our NPC framework captures the features and functionalities of the many 
information system types that have emerged to support individual requirements 
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Fig. 1. Detail of an example NPC network. 



of information dissemination and retrieval. In its role as an unifying framework 
for heterogeneous functionalities, it must provide the following features: 

Openness and extensibility: our framework is generic in the sense that support 
for arbitrary document and metadata formats, as well as support for a wide range 
of query and filtering languages, transmission protocols, and manipulations of 
document streams can be plugged in. 

Interoperability with existing systems is a consequence of the extensibility 
with various transmission protocols. 

Protocol Transparency: As Franklin and Zdonik put it in FZ97|, "the char- 
acter of a link should be of concern only to the nodes on either end". This means 
that the model treats different protocol characteristics such as push/pull or peri- 
odic/aperiodic in a transparent way. Moreover, different and even mixed models 
should be supported simultaneously as in the case of a mailing-list server (push) 
with integrated archive (pull), or in the case of an document repository (pull) 
offering a notification service for its catalog (push). 

Modularity is achieved by offering a building kit of elements that can be 
freely combined to build networks. 

Evolution and Management: IDNs must be able to adapt to changing de- 
mand and supply of information by providing for dynamic reconfiguration. The 
information dissemination mechanism lends itself naturally to transport the nec- 
essary administrative information. NPC ports are able to inspect and to change 
the configuration of their parent nodes in reaction to events or external requests. 

Filtering, document conversion, (dis) aggregation: Ports may arbitrarily pro- 
cess the document streams passing through them. This includes the deletion of 
selected documents (filtering), arbitrary transformations of single documents, 
combination of documents into aggregated documents (such as archives) as well 
as disaggregation of documents into multiple documents. 

Scheduling: Many applications require the scheduled and periodic delivery of 
information. This is supported in our framework by means of time events. 

Coordination of Demand and Supply: To support demand-driven delivery of 
information, the information demand and its termination must be propagated 
across a network from consumers to information providers. The complementary 
requirement is the advertisement of information offers to potential consumers. 



Security is crucial in all distributed systems. Our model supports the imple- 
mentation of a large range of security policies. The use of existing authentica- 
tion and encryption protocols is supported through its extensibility with various 
transmission protocols and the support for arbitrary document conversions. 

Contents The rest of the paper is organized as follows: we present the concep- 
tual model of NPC in Sec. [21 The central protocol for communication between 
nodes and their ports is presented in Sec. [21 Then we demonstrate in Sec. 0] 
several applications of the NPC approach. In Sec. HO we discuss related work. 
Some extensions of our model are discussed in Sec[S] We conclude and give an 
outlook in Sec. [7| 

2 Conceptual Model 

The principal components of the NPC framework are Nodes, Ports and Channels. 
Intuitively, documents are transferred between nodes across communication chan- 
nels, whereby a node may have more than one communication port. To capture 
the functionalities of an IDN in a generic way, a more elaborate data model is 
required, though, which is presented in Fig. [21 as an UML class diagram. As can 
be seen in the left side of the figure, a node may have documents, ports and 
subnodes (to be explained later) attached to it by means of Entries. Nodes are 
contained within Servers that are located on physical hosts. Channels are mod- 
eled as associations between ports and Resources which specialize into Ports and 
Externa I Resources. The latter may be any external software system offering a 
well-defined communication protocol; e.g., a Web server/browser, a file system, 
a database server etc. A Port communicates with its parent node by exchanging 
Events (c.f. Sec. l2.2l3|l that arc archived in an eventHistory. It communicates with 
resources on other servers via Gateways (c.f. Sec. l2.3[) . We stress that each node, 
port, and gateway in an NPC network may have an individual implementation 
which enables the support for heterogeneous document and metadata formats, 
protocols, conversions, and filter languages. 

Example 1. (Forwarding) A simple NPC application forwards all new documents 
from a "provider node" to a "consumer node" via a channel. A new document en- 
try is inserted by posting an Insert event to the provider node. A "provider port" 
at this node consumes the Insert event and communicates its contents to a "con- 
sumer port" at the consumer node (via suitable gateway objects understanding a 
common communication protocol). The consumer port inserts the document by 
emitting a corresponding Insert event. In addition, the provider port may delete 
forwarded document entries by emitting Remove events for them. 

2.1 Nodes 

Each Node stores a set of Entries that are uniquely named within the node. Each 
entry belongs to a single node and consists of: (i) a metadata record describing 
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Fig. 2. A conceptual model of NPC networks (UML class diagram). 



the content of the entry, (ii) the proper content of the entry, which may be either 
a Document, a Node, or a Port. Hence we speak of document entries, node entries, 
and port entries. Node entries enable the construction of node hierarchies similar 
to directory trees in file systems. We require that each server has a unique root 
node. Then each entry can be uniquely addressed by a URL that consists of the 
host address of the server and a sequence of entry names describing the path 
from the root node via a chain of subnodes to the entry. 



2.2 Events 

Events describe state changes in a node. The state of a node is its content, i.e., 
its set of entries. Each node keeps a history of events ordered by creation time. 
Every event posted by a port is received by its node, recorded in the event history, 
and delivered to all other ports. The two most basic types of events produced 
by ports are Insert and Remove events. An Insert event causes the node to insert 
a new entry specified by the event. Similarly, a Remove event causes the node 
to delete the entry named by the event. Newer events may cancel older events 
in the event history. For instance, a Remove event for an entry may delete the 
preceding Insert event for this entry. In addition, a node may have some policy 
for discarding old events. 

Example 2. (Replication) Example ^ can be extended to support mirroring of 
repositories by transmitting not only Insert events, but also Remove events. Thus 
both insertions and deletions at the provider node are propagated to the con- 
sumer node where they are mirrored. By adding a back channel, bidirectional 



mirroring can be achieved. To distinguish originals from replicas each entry is 
tagged with its originating node. More complex replication schemes such as the 
I2-DSI architecture DBM99 can be supported as well. 

Entries can be accessed through the events referring to them. In particu- 
lar, the contents of a removed entry may be still accessible through the event 
describing its removal, depending on the node implementation. In addition to 
EntryEvents referencing an entry, there are further event types such as FlowEvents 
for flow control and TimeEvents for scheduling (c.f. Fig. 

2.3 Gateways 

Each server hosts a number of Gateways which are in charge of communication 
with (gateways at) other servers or external resources. Each gateway implements 
a specific communication protocol. The communication between the ports form- 
ing a channel is routed via gateways as illustrated in Fig. El Gateways and ports 
communicate via a protocol-spccihc API. Incoming connections may indicate to 
the gateway which port they want to contact by specifying its URL. 



2.4 Ports 

Ports are persistent processes that enable the communication between nodes 
and resources, including the ports of other nodes, via gateways. Most ports are 
unidirectional in- and out-ports. In-ports transform an incoming data stream 
into a stream of events that are posted to the parent node. Conversely, out-ports 
consume an event stream and turn it into an outgoing data stream. 

Example 3. (Filtering, Conversion, Aggregation) The ports involved in Exam- 
ple |21 may be designed to forward/accept only documents matching certain fil- 
tering criteria. The ports may convert the forwarded documents, for instance by 
applying XSL stylesheets to XML documents. The provider port may even pack 
several documents into archive files which are unpacked by the consumer port. 
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Fig. 3. Implementation of a channel. 



Properties of a Port: (i) Ports may be in-ports, out-ports, or bidirectional, 
(ii) Their operation may be periodic or a-periodic. (iii) The communication with 
the external resource may follow the push-, pull-, or a mixed model. We call 
the combinations in-port + push and out-port + pull externally driven, the 
combinations in-port + pull and out-port + push internally driven. 

Example 4- (Push vs. Pull) Example^can be implemented using cither push- or 
pull-mode communication. In aperiodic push-mode, the provider port is triggered 
by the Insert events posted to the event history of the provider node. For each 
Insert event the provider port feeds the new document to the consumer port. 
In periodic pull-mode, the consumer port is triggered by time events at the 
consumer node to poll the provider port for new documents. Only if triggered 
by the consumer port does the provider port request the next insert events from 
the provider node and transmit the referred documents to the consumer port. An 
application of this scheme would be to periodically fetch new metadata records 
from an OAI LdSOl repository. 

Event filters. For security and efficiency reasons, ports need not receive all 
events nor should they be able to emit arbitrary events. Each port entry con- 
tains as metadata two filter expressions, the input and the output filter. They 
are interpreted by the node to restrict which events the port may receive and 
produce, respectively. Proper in-/out-ports can be enforced by blocking out- 
put/input filters. Different node implementations may support different filter 
languages of varying expressiveness. Filter conditions may reference properties 
of events as well as metadata and content of the entry an EntryEvent refers to. 

Metaports. Ports that are restricted to receive or generate Insert or Remove 
events for document entries only are called plain ports. All other ports we call 
metaports. Only metaports are allowed to inspect, insert, or delete port entries 
and subnode entries. Metaports provide a reflexive and introspective mechanism 
for evolution and remote management of NPC networks. Metaports are called 
admin ports if their filters allow arbitrary events to pass. For security reasons, 
communication with metaports (and admin ports in particular) should be pro- 
tected by suitable authentication and encryption techniques. 

Security Policies have to be enforced by choosing appropriate input/output 
filters. Basic objectives of such a policy are to ensure that plain ports can only 
read or write document entries and that meta ports cannot insert port entries 
which violate the security policy. Further objectives may be to hide certain 
entries from certain ports or to restrict which ports can delete certain entries. 

2.5 Channels 

NPC channels are unidirectional communication relationships between nodes. A 
channel transmits a stream of data items from a source node to a target node via 
a port and a gateway at each end of the channel (c.f. Fig. IS}. A channel may also 
connect a node to some other external resource. Bidirectional streams between 
nodes are implemented as pairs of channels. 



Document channels transmit streams of documents. Document channels are 
generalized by entry channels that copy entries from the source node to the 
target node. Entry channels allow to transmit also non-document entries. Event 
channels generalize entry channels further by transmitting arbitrary event streams 
which may also propagate deletions of entries. 

Ports may be created without being part of a channel and they may survive 
the termination of the channel they are participating in. Ports are intended to 
participate in no more than one channel at a time, except in cases like bidirec- 
tional ports. Instead of multiple channels ending in the same port, the advisable 
method is to create a dedicated port for each new channel. 

To establish a new channel between a source node and a target node, a 
source port and a target port need to exist. One of these ports contacts the 
other port (via suitable gateways). Ports may delegate incoming connections 
to other ports and may even create new ports to this purpose. Thus a node 
can support arbitrary numbers of incoming or outgoing channels with dedicated 
ports. Various policies for connection pools can be implemented as well this way. 

3 Unifying the Push- and Pull-Model 

The communication between a node and its ports via the event history is illus- 
trated in Fig. Q] This diagram depicts an in-port that currently deletes entry 1 
by writing a delete event and an out-port that is just reading an earlier event 
describing the insertion of entry 2. Both ports are communicating with external 
resources. The details of the interaction between a port and the event queue 
are specified by the node/port protocol that is introduced in the sequel of this 
section. 

As argued in the introduction, information dissemination frameworks need 
to support various communication models. In the NPC framework, both push- 
model and pull-model communication are generalized into the node/port com- 
munication protocol. The communication between a node and its ports is entirely 
event-based. A port can only post events to its parent node that pass its output 
filter. On arrival at the node, events may trigger state changes such as insertion 
or removal of entries. By default, every event is entered into the node's event 
history. FlowEvents control the delivery of events to a port. 

The sequence diagram in Fig. 03 illustrates the flow control in the node/port 
protocol. Each port entry stores a receive flag to indicate whether the port is 
currently accepting input events. The port may set this flag by issuing a Receive 
event which is not added to the event history (1). After the receive flag has been 
set, the node starts delivering events from the event history to the port (2). Only 
events passing the input filter of the port entry are delivered to this port. Each 
port entry also contains a cursor pointing into the event history to keep track 
of the events already delivered. The node implementation should guarantee a 
fair delivery of events, i.e., eventually every interested port will receive every 
event. Nodes may also implement delivery policies that honor Quality- of- Service 
requirements stated in the metadata of port entries. 
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Fig. 4. The event history and ports of a node. 



A port may suspend the delivery of events temporarily by issuing a Suspend 
event which clears its receive flag (3). After having issued a Resume event (4) 
the receive flag is set again and the port continues to receive events (5). After 
the cursor of a port has reached the end of the event history, the node issues a 
Suspend event to the port which clears its receive flag (6). If the port wants to 
wait for future events, it has to emit again a Resume event (7). If the cursor is 
still at the end of the event history at this time, the Resume event is posted to 
the event history which may trigger interested in-ports to post events matching 
the input- filter of the out-port (8). Only those events that actually pass the 
input- filter are delivered to the out-port. A port can terminate the delivery of 
events by issuing a Close event (9). This cancels any preceding Resume events 
and is received by interested in-ports which in turn may stop event delivery. 

An important advantage of the node/port-protocol is its support both for 
the push and pull communication model: In the push-model external producers 
send data to in-ports of a node which post it in form of Insert events. Out-ports 
of this node receive these events and forward the data to external consumers, 
including in-ports of other nodes. Thus information can be pushed from providers 
to consumers across a NPC network. 

The pull-model requires more coordination: An external consumer connected 
to an out-port causes it to emit a Receive event. After having received all historic 
events the out-port issues a Resume event which is received by all interested in- 
ports (c.f. Fig.EJ. These in-ports may retrieve data from external producers and 
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Fig. 5. The node/port protocol as an UML sequence diagram. 



post it in form of Insert events that are received by all out-ports with matching 
input filters, including the out-port that has triggered the import. This enables 
consumers to pull information from providers across a NPC network. In-ports 
may achieve finer flow control by also monitoring Suspend and Close events. 

4 Applications 

In this section we present some example applications and how they can be im- 
plemented using the NPC approach. 

Mailing Lists. A mailing list can be implemented using a single node 
(Fig.|SJ). An active "administration" in-port periodically fetches (un-)subscription 
messages via some gateway from an external mail server. The administrator 
port transforms each (un-)subscription message into an insert (remove) event of 
a "subscriber" out-port. A "submission port" periodically fetches submissions 
from the mail server. For each received message it emits an Insert event which is 
received by the subscriber ports and sent to each subscriber using a gateway to 
the external mail server. Subscriber ports may convert messages into a format 
preferred by the subscriber and bundle several messages into message digests. 
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Fig. 6. A mailing list (gateways and mail server omitted). 



All messages are archived in the mailing list node (unless a "garbage col- 
lector" port is deleting old messages). In paragraph "Simple Document Server" 
below we explain how to add a Web interface for this archive. 



Alerting Systems. The mailing list application can be easily extended to 
build alerting systems that filter the incoming documents on behalf of their 
subscribers. Each subscriber port uses its input filter (and possibly internal post- 
processing) to forward only those documents the subscriber is interested in. 
To handle a large number of subscriptions efficiently, the node may index the 
input filters of its subscriber ports to deliver incoming events only to matching 
subscriber ports (c.f. |YGM94p . 

Hierarchical Document Classification. Documents can be classified into 
a subject hierarchy by modeling the subject hierarchy as an NPC network as 
depicted in Fig. [7| Each node represents a subject class, its subnodes represent 
its subclasses. For each subnode there exists an out-port that forwards messages 
to an in-port of the subnode. This out-port implements a classifier that permits 
only those documents belonging to the class represented by the subnode. Note 
that classifiers need not necessarily be automated, they may as well prompt a 
human expert for advice. 




Fig. 7. A classification hierarchy for document filtering. 



Incoming documents are fed into the root node of this hierarchy and are 
distributed to those nodes representing the classes they fit. 

Simple Document Server. A node storing a document collection can act as 
a simple (HTTP) document server. A document request from a client is received 
by an admin-port via a HTTP gateway which inserts a dedicated "request port" 
into the node. The request port specifies the name of the requested document 
in its input filter. After receiving the recorded Insert event for the requested 
document entry, the request port reads the document stored in this entry and 
sends it to the client. For a missing document the request port receives a Suspend 
event instead and sends an error message to the client. In both cases, the port 
removes itself from the node by emitting a Remove event for itself. 

Information Retrieval. Information retrieval from a document repository 
is a generalization of the simple document server application mentioned above. 
Instead of request ports we speak of "query ports" in this context. Instead of a 
single document, a query port may return a set of documents. 



The input filter of a query port preselects potential result documents. The 
query port post-processes the events passed by the filter depending on the ex- 
pressiveness of the node's filter language. Each matching document is returned 
to the client. A node may maintain an internal index for its event history and 
use it when evaluating new filter expressions against existing events. 

The query port may also collect and order the matching documents according 
to some relevance measure. The query node receives a Suspend event after the 
event history is exhausted. It then delivers the result as a ranked list to the client 
cither in one part or in several portions of fixed size. 

Query Mediation. In networked information retrieval, a query from a client 
against a mediator is processed by forwarding it to several source repositories. 
Wrappers translate between the mediator query language and the heterogeneous 
source query languages. They also convert the returned results into a common 
format. The mediator returns the combined results to the client. 

In NPC, a query mediator can be implemented as follows: Each query port 
entry states its query in its metadata. For each source repository there exists a 
"query translator port" in the mediator node which monitors the Receive events 
posted by query ports, analyzes each query and decides whether to delegate it 
to its source repository. In this case it inserts a "wrapper port" supplied with 
the name of the query port repository-specific translation of the query. The 
query port name is also stored in the wrapper port metadata. The wrapper port 
queries its source repository, posts the received results (tagged with the query 
port name), and finally removes itself from the node. 

The query port subscribes to Insert events for document entries tagged with 
its own name, removes them from the node, and returns the documents to the 
client. It may also filter, collect, sort, and group the results before returning 
them. The query port also monitors insertions and removals of wrapper ports to 
check whether all wrapper ports for the query have terminated. 

If the client aborts the query, the query port removes all wrapper ports for 
this query. Each wrapper port is notified of its own removal by a Remove event 
which triggers it to propagate the abort to its repository and then to terminate. 
Finally, the query port removes itself and terminates as well. 

Further application areas include workflow management (using a document- 
flow centered view), hierarchical document filtering, network management, Web- 
caching, and peer-to-peer information dissemination networks. 

5 Extensions 

5.1 Exclusive consumption of events 

In certain applications it is important to deliver an event exclusively to a single 
port. When a node receives an event, it returns a flag that determines whether 
the event is consumed by the port or delivered to further ports. By attaching 
a priority to each port, a partial ordering for the event delivery is introduced. 
Ports of equal priority may be ordered in a nondetcrministic way. 



5.2 External Security Policies 



In the NPC model presented so far, every port is free to communicate with 
arbitrary resources via suitable gateway objects. Input and output filters control 
only the information exchange between nodes and ports. The right place to 
control the communication between ports and external resources or ports is at 
the gateway objects. 

External security policies which restrict this communication may be defined 
as sets of firewall rules similar to those used by typical firewall software. Such 
security policies may be either global or are attached as metadata to port or 
subnode entries. A security policy attached to a subnode entry applies to all 
ports in the tree rooted in the subnode entry and is subject to refinement by 
security policies in nodes or ports deeper within this tree. 

This approach can be extended to control intra-server communication by 
requiring that all communication between ports on the same server has to be 
routed as well through gateway objects. 



5.3 Dynamic subscriptions 

The input filter of a port serves a twofold purpose: it reflects the security policy of 
the node and the interests of the port. While the security policy can be considered 
to be static, the interests of the port may change over time. Moreover, a port may 
want to maintain several subscriptions for the event queue that it can control 
independently (via receive, suspend, resume, close events). 

For instance, a port may initially subscribe to a future time event and only 
after receiving this time event it will subscribe to other events. 

To cater these needs we propose to change the node/port protocol as follows: 
two parameters arc added to receive events, a filter expression and a subscrip- 
tion name chosen by the port. The subscription name is used to reference the 
subscription in suspend, resume, and close events. Subscription names need to 
be unique only within each port. 

In the example, the port would first emit a receive event specifying a filter 
condition for a future time event. After receiving this time event, the port would 
emit a close event for this first subscription and a receive event specifying the 
second subscription. 



6 Related Work 

Message-oriented middleware such as the Java Messaging Service (JMS) stan- 
dard |Mic99| . IBM MQ- Series |MQ-02| , Oracle Advanced Queueing jOra02j . and 
Talarian SmartSockets jSmaOOj offer message queues and topics to connect sup- 
plier and consumer clients. Extra client-side programming is needed to connect 
queues or topics to a larger network. Clients may specify filter-expressions on 
the message header fields in a simple and fixed filter language. The object-based 
CORBA notification service |CNS| does not have these shortcomings. Moreover 



it supports the propagation of demand for and the supply of certain event types. 
However, this mechanism is external to the event propagation mechanism and 
it does not allow the propagation of more complex queries as in NPC. All men- 
tioned systems are missing introspective means for management and evolution 
as in our model. Channels in our model could be based on these systems. 

Siena CRW01 is a push-model publish/subscribe system for alerting within 
a wide-area network. It offers scalability by distributing filters over servers within 
the network and saving bandwidth by filtering close to the event sources and 
bundling similar subscriptions. Siena is modular and offers sophisticated filtering 
mechanisms including dynamic configuration and distribution. It lacks openness, 
document stream transformation, and scheduling. 

Elvin4 |SAB + 0f)] is an alerting system based on a client-server-client archi- 
tecture. It is open for different transport, security, and marshalling mechanisms. 
Elvin4 is not intended to scale to wide-area networks or to go beyond pub- 
lish/subscribe systems. Its quenching mechanism prevents the publication of 
events for which there exists no consumer. This is similar, but less general than 
the query-propagation mechanism offered by our model. 

The Information and Content Exchange (ICE) protocol ICEOO is an XML- 
and HTTP-based standard for content syndication that could be supported by 
our framework. Providers advertise information delivery offers which consumers 
may subscribe to. Both push- and pull-delivery is supported. 

Alerting systems based on Continual Queries such as CQ |LPT+I IlPT99| 
and WebCQ LTBP02 have been developed to track changes in databases and on 
Web sites. The focus here is on efficient detection and meaningful summarization 
rather than on openness or modularity. CQ systems could be used as information 
providers within the NPC framework. 

For a survey on further event-based systems, see jp,K98 . 



7 Conclusion and Outlook 

The NPC approach presented here offers an unifying framework for building 
a wide range of information dissemination networks built from nodes, ports, 
and channels. It is open for heterogeneous protocols, filtering languages, docu- 
ment and metadata formats by allowing different node and port implementations 
within the same IDN. Moreover, existing document processing technology can 
be easily incorporated into nodes and ports which enables all kinds of filter- 
ing operations, format conversions, and (dis)aggregation operations. Due to its 
openness, NPC is also interoperable with a wide range of existing IDS. By using 
a general event-based node/port communication protocol, the heterogeneity of 
the underlying port/port communication protocols is hidden. In particular, it 
supports both supply-driven (push-model) and demand-driven (pull-model) in- 
formation dissemination across an IDN. Other important features are dynamic 
and reflexive configurability, support of scheduling, and of security policies. 



The generality of the NPC approach supports various applications, from 
newsgroups to query mediation, and facilitates the development of innovative 
information dissemination applications. 

Due to space limitations several interesting extensions had to be omitted, 
e.g., complex events, exclusive consumption of events, dynamic subscriptions, 
and external security policies. A Java implementation of the node/port proto- 
col is available at |Fau03| . We are currently extending it to a full-fledged IDN 
construction kit. 
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